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Abstract 



The computer controlled financial transaction system has a customer unit Al0, a dealer unit A2U and a 
finance controller A3U that are coupled together by a data bus A6a,b,cU that provides a secure transfer of 
data. A contract module A8U as a specific finance module is connected by adapters A10Q. The customer 
unit has a selection module A14U that is software based for specific finance systems. 
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(54) Verfahren zur rechnergestOtzten Zahlungsabwlddung Ober Zahfungssysteme 

(57) Die Erfindung bezeichnet ein Vertahren zur 
rechnergestOtzten ZahiungsabwickJung ober Zahfungs- 
systeme unter der Zwischenschaftung eines Finanz- 
dienstteisters (3) der dieses Zahlungssystem (4) 
unterstotzt. wobei eine stchere Obertragung von Daten 
Ober Datenverbindungen (6a), (6b), (6c) in Netzen (5) 
gewfthrleistet wird. Die Aufgabe besteht darin, dem 
Handler (2) mehrere fOr den Kunden (1) mOgliche Zah- 
lungssysteme (4) zur VerfOgung zu stellen, ohne den 
Handler (2) selbst zur Integration dieser Zahlungssy- 
steme (4) zu zwingen. Dies wird gelOst. indem von 
einem Vertragsmodul (8) des Rnanzdienstleisters (3) 
dem Handler (2) ein neutral es Hflndler-Vertr a g sp iolo- 
koli (19) zur VerfOgung gestelft wird, Ober welches eine 
beidsertige VerpfOchtung zwischen dem Handler (2) und 
dem Kunden (1) abgeschlossen und diese dem Ver- 
tragsmodul (8) Gbermrttert wird. In den weiteren Verfah- 
rensschritten wird die ZahiungsabwickJung des Kunden 
(1) in senem speziellen Zahlungssystem (4) sicherge- 
steirt und dessen Status dem Handler (5) ubermjtteft 
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Beschreibung 

[0001] Die Erfindung bezeichnet ein Verfahren zur 
rechnergestOtzten ZaWungsabwicHung uber Zahlungs- 
systeme, betreffend einer beidseitigen Verpfttchtung, s 
insbesondere eines Kaufvertrages, zwischen einem 
Kunden und einem Handler unter der Zwischenschal- 
tung eines Finanzdienstleisters, insbesondere einer 
BanK der dieses Zahlungssystem unterstutzt, wobei 
durch spezielle Ubertragungssysteme eine sichere 10 
Ubertragung von Daten Qber Datenverbindungen in 
Netzen gewahrleistet wird. 

[0002] UWicherweise bietet ein Handler den Kunden 
bestimmte Waren an, die der Kunde auswahlt Hat sich 
der Kunde zum Kauf entschlossen, kommt es zum is 
AbschluB eines Kaufvertrages zwischen dem Kunden 
und dem Handler. In Folge des Vertrages zahlt der 
Kunde in einem Zahlungsverfahren (bsw. durch Barzah- 
lung) den Kaufpreis und der Handler ubergtot die ver- 
kaufte Ware. 20 
[0003] Eine modifizierte Variante dieses Zahlungsver- 
fahrens stellt der Kauf Qber Kreditkarten Oder Qber ahn- 
liche Zahlungssysteme dar. Dabei wird ein 
Zahlungssystembetreiber, zumeist eine Bank, zwischen 
den Handler und den Kunden geschattet Der Kunde 25 
bezahlt demnach nicht direkt, sondern der Zahlungssy- 
stembetreiber burgt (mittels der Kreditkarte) fur die Zah- 
lungsfahigkeit des Kunden. Zu einem spateren 
Zertpunkt bucht der Zahlungssystembetreiber den faiii- 
gen Kaufpreis vom Konto des Kunden ab und uberwetst 30 
den Kaufpreis auf das Konto des Handlers. Fur diesen 
Vorgang verfangt er ubticherweise eine GebOhr. In der 
Praxis sind unterschiedliche Zahlungssysteme mit ver- 
schiedenen Konditionen fur unterschiedliche Einsatz- 
zwecke notwendig. 35 
[0004] Viele moderne Zahlungssysteme sind ate Son- 
derfunktionen von DVA (Datenverarbettungsardagen) 
rechnergestutzt ausfuhrbar (IPC G06F 17/60). Dieser 
technische Hintergrund wird betspiefsweise in der 
Druckschrift EP OS 0668 579 A2 im Zusammenhang 
mit Keditkarten und in der Druckschrift WO 95/19010 im 
Zusammenhang mit Homebankingsystemen erw&hnt 
Diese unterschiedlichen Zahlungssysteme der einzel- 
nen Zahlungssystembetreiber sind jeweils modifiziert 
und in der Regel unterei render nicht Oder nur einge- 4s 
schrankt kompatibel. BezOgiich des inter nationalen 
Zahlungsverkehrs sind natbnale Zahtungsmrttel men- 
genmaBig verbreiteter als einzelne internationale Zah- 
lungssysteme. 

[0005] Moderne Ubertragungssysteme fur (reformatio- so 
nen fur Datenverbindungen im Fernverkehr (IPC H04L), 
beispielsweise das Internet ermOglichen die Werbung 
des Handlers Qber diese Ubertragungssysteme. Dazu 
bietet der Handler eine Werbeinformation an, Qber we*- 
che er seine Waren prasentiert. Mrttete eines vorgefer- 55 
tigten Kaufvertrages kann der Kunde bequem den 
Kaufvertrag rechtskrdftig werden lassen, indem er den 
unterschriebenen Kaufvertrag an den Hander sendet 



beispielsweise per Post, per Fax Oder Qber andere 
(rechtiich anerkannte) elektronische Ubertragungssy- 
steme. 

[0006] Bet der Ubermitttung von Daten (persCnliche 
Informationen aus Kaufvertragen, Einzelheiten der Zah- 
lungsabwicWung) auf modemen Ubertragungssyste- 
men (z.B. im Internet) besteht jedoch die Gefahr der 
unberechtigten Kenntnis, Benutzung oder Modrf izierung 
dieser Daten. Aus diesem Gmnd wurden kryptographi- 
sche Verfahren entwickelt. die auch auf elektronischen 
Wege eine sichere Ubertragung, das heiftt sicher vor 
Manipulation und Zugriff, von Daten zwischen zwei Teil- 
nehmern ermOglichen (IPC H04L 9/00). Dieser techni- 
sche Hintergrund wird bsw. in der Druckschrift WO 
97/16779 im Zusammenhang mit der Eingabesicherung 
und Infbrmationsubertragung sowie in der Druckschrift 
EP OS 0668 580 A1 im Zusammenhang mit der 
Authentisierung der Teilnehmer erwahnt. 
[0007] Derartige kryptographische Verfahren werden 
jeweils in einem spezrfischen Zahtungsmodul realisiert 
und kOnnen Hardware basierend und Software basie- 
rend sein. Im ersten Fall benOtigt jeder Teilnehmer eine 
(gQnstig individuelle) Hardware zur Ver- und Errtschlus- 
selung der Daten. Im zweiten Fall wird dies bei zumin- 
dest einem Teilnehmer durch identische Hardware mft 
(gunstig individuellen) verschlusseften Parametern 
erzieft (andern sich zumeist in der Zeitsparme einer 
mOglichen EntschlQsselung dieser). Bei Finanzdienst- 
feistern, insbesondere bei Banken, ist eine rechnerge- 
stutzte Zahtungsabwickfung (IPC G06F 19/00) bei 
modemen Obertragungssystemen (z.B. im Internet) nur 
Arisatzweise mit spezrfischen Zahlungssystemen eta- 
Wiert (z.B. SET(secure electronic transrrjon)). 
[0008] Durch die vietfaitigen MOglichkeiten zum 
AbschluB eines Vertrages zwischen dem Kunden und 
dem Handler, insbesondere auf elektronischem Wege, 
hat der Kunde die Mdglichkert, zwischen den verschie- 
denen Zahlungsverfahren (Barzahlung per Nach- 
nahme, Uberweisung, Lastschrrft, Kreditkarte, ...), den 
mOglichen Zahlungssystemen (z.B. VISA- Card; EC- 
Kreditkarte; SET, PIN/TAN(personal identity num- 
ber/transaction indetity number), Geldkarte, ...) und den 
damrt vertxindenen Kbncfitionen auszuwahlen. Dies 
setzt jedoch voraus, daB der Handler diese Zahlungs- 
verfahren und Zahlungssysteme anbietei 
[0009] Im Interesse der Kundenorientierung ist der 
Handler in der Regel bemuht samtliche Zahlungsver- 
fahren und Zahlungssysteme anzubieten. Dieses 
BemOhen bedingt jedoch fur den Handler notwendig die 
integration dieser Zahlungssysteme, verbunden rrtit 
einem groBen organisatorischen Aufwand (z.B. jeweils 
verschiedene Konten), Unkosten (fOr die Teilnahme an 
den jeweiligen Zahlungssystemen), einem hohen 
Kbstenrisiko und der Notwendigkert, die notwendigen 
Mrttel fur (fie entsprechenden Zahlungssysteme (Kredrt- 
kartenleser, ZaWungsmodule) stets einsatzbereit zur 
VerfOgung zu halten. Aus diesen GrQnden sind Zah- 
lungssysteme fur Handler sehr kompfiziert integrierbar 
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und neu entwtckefte schwer in groBem MaBstab anzu- 
fuhren. 

[0010] Die Aufgabe der Erfindung ist es, ein oben 
beschriebenes Verfahren zur rechnergestutzten Zah- 
lungsabwicklung Ober Zahlungssysteme zu entwickeln, s 
welche die aufgefuhrten Nachteile besertigt und dem 
Handier mehrere fur den Kunden mOgliche Zahlungssy- 
steme zur Verfugung stellt, ohneden Handler setbst zur 
Integration dieser Zahlungssysteme zu zwingen. 
[001 1 ] Die Aufgabe wird durch die im Paterttanspruch to 
1 aufgefuhrten Merkmale gelOst. Bevorzugte Weiterbil- 
dungen ergeben sich aus den Unteranspruchen. 
[0012] Das Wesen der Erfindung besteht darin, da 8 
Ober eine geschlossene Datenverbindung Ober Netze 
in einem 1. Schritt is 
der Kunde seine gewunschten Waren und Zahlungssy- 
steme dem Handler Ober die Datenverbindung mitteilt 
und danach durch den Handler die Kundenmrtialisie- 
rung des Kunden erfolgt, 

in einen 2. Schritt 20 
der Handler Ober eine Datenverbindung zu einem Ver- 
tragsmodul bei einem Rnanzdienstleister die Konditio- 
nen fur tie gewunschten Zahlungssysteme abfragt und 
dieses sie ihm sicher ubermittert, 
in einem 3. Schritt 25 
der Handler Ober die Datenverbindung dem Kunden 
sicher ein Auswahl-Modul ubermittelt, welches, jeweite 
einzeln for die gewunschten und verfugbaren Zahlungs- 
systeme. das KonKrete Angebot des Handlers an den 
Kunden beinhaltet, 30 
in einem 4. Schritt 

der Kunde ein einzelnes konkretes Angebot des Hand- 
lers im Auswahl-Modul auswahlt und damit eine beidsei- 
tige Verpffichtung eingeht. der en Inhatt das Auswahl- 
Modul sicher Ober die Datenverbindung dem Handler 35 
und sicher Ober die Datenverbindung dem Vertragsmo- 
dul ubermittelt, welches sie auf ihre Richtigkeit uber- 
pruft und unter der eindeutigen ProzeBnummer 
speichert, 

in einem 5. Schritt 40 
das Auswahl-Modul tie fur das ausgewahlte spezifische 
Zahfungssystem verfOgbare sichere Datenverbindung 
zwischen einem spezifischen Kunden-Zahlungsmodui 
und dem zugeordneten spezifischen Vertragsmodul- 
Zahlungsmodul aktiviert und den Inhaft der beidseitigen «s 
Verpffichtung dem spezifischen Zahlungssystem Ober- 
gitrt. 

in einem 6. Schritt 

der Kunde die notwendigen Ergdnzungen in dem spezi- 
fischen Zahlungssystem vomimmt und die Zahlungsab- so 
wicklung mit dem Handler uber das spezifische 
Kunden-Zahlungsmodui, die Datenverbindung und das 
spezifische Vertragsrnodul-Zahlungsmodul sicher 
anweist 

in einem 7. Schritt ss 
das spezifische Vertragsrnodul-Zahlungsmodul tie 
angewtesene Zahlungsabwicktung an eine spezifische 
Zahlungssystem- OVA des spezifischen Zahtungssy- 



stembetr eibers t&tigt 
in einem 8. Schritt 

das Vertragsmodul die spezifische Zahlungssystem- 
DVA des spezifischen Zahlungssystembetreibers liest, 
dessen Eintrage mit dem gespeicherten Inhalt der beid- 
seitigen Verpflichtung vergleicht und uber die Datenver- 
bindung den Handler sicher uber den Status der 
Zahlungsabwicklung informiert, 
in einem 9. Schritt 

die Uberweisung von der spezifischen Zahlungssy- 
stem-DVA auf das Korrto des Handlers erfolgt 
[001 3] Die Vorteile der Erfindung I i eg en insbesondere 
in Folgendem: 

Der Handler mu(3 die einzelnen spezifischen Zah- 
lungssysteme drrtter Zahlungssystembetreiber 
nicht selbst integrieren, da dies Geweils ein mal) der 
Rnanzdienstleister des Handlers ubernimmt 
Das Vertragsmodul Qberwacht im Interesse des 
Handlers die Erfullung der sich aus dem beidseitig 
verpftichtenden Vertrag fOr den Kunden ergebende 
Zahlungsverpflichtung, die dieser mit einem dritten 
Zahlungssystembetreiber abwickeft Der Handler 
erhatt dadurch die notwendige Sicherheit fOr die 
Erfullung der Verpflichtung seinerseits. 

• Speziell fur die Datenverbindung Handler - Rnanz- 
dienstleister ist vorteilhaft, daB der Handler eine 
zertrfizierte Zahlungsbestatigung fur die Erfullung 
der sich aus der beidseitigen Verpflichtung erge- 
benden Zahlungsanweisung des Kunden erhatt, die 
Signatur prufen kann und alle notwendigen ProzeB- 
daten im Vertragsprotokoil mitgeliefert bekommt. 

• Speziell fur die Datenverbindung Handler - Kunde 
besteht eine Kanalsicherhert (bsw. uber einen 
SSL), die Handleridentitat und Richtigkeit der 
Bestelidaten ist durch den Kunden prufbar, das Ver- 
tragsprotokoil hat alle notwendigen ProzeBdaten. 
so daB bei Datenausfall in den Basissystemen das 
Vertragsprotokoil aus sich selbst regeneriert wer- 
den kann. Der Handler arbeitet stets mit demselben 
neutralen Vertragsprotokoil. unabhangig von dem 
spezifischen Zahlungssystembetreiber des Kun- 
den. Dieser wiederum kann seine gewohnten Zah- 
lungsanweisungen uber seinen spezifischen 
Zahlungssystembetreiber abwickeln und nutzt des- 
sen MOgfichkeiten voll aus. 

• Speziell fur die Verbindung Kunde - Rnanztienst- 
leister, da die Kundendaten nicht durch das Ver- 
tragsmodul an den Rnanzdienstleister ubergeben 
werden. Die Zahlungsabwicklung erfolgt direkt zwi- 
schen dem Kunden und dem spezifischen Zah- 
lungssystembetreiber (Eigenschaften des 
spezifischen Zahlungssystems gerten) 

Alle Datenverbindungen uber Netze sind durch die 
Verwendung von Krytographie sicher. 

[0014] Die Erfindung wird als Ausfuhrungsbeispiel an 
Hand von 
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Fig. 1 als Schema einer Zahlungsabwicklung 
naher erlautert 

[001 5] Nach Rg. 1 wird eine Zahlungsabwicklung not- 
wendig, wenn ein Kunde 1 die Werbung eines Handlers 
2, welcher mit einem Rnanzdienstleister 3 (insbesond- 
ere mit Ban ken) in Geschaftsverbindung stent pruft, 
eine beidseitige Verpflichtung (z.B. einen Kaufvertrag) 
einzugehen beabsichtigt und die ihn interessierenden 
gewunschten Waren und Zahlungssysteme 4 (z.B. SET, 
EURO-Cash) auswahtt. FOr eine Ubertragung von 
Daten sind der Finanzdienstleister 3 mit dem Kunden 1 , 
der Finanzdienstleister 3 mit dem Handler 2 sowie der 
Kunde 1 mit dem Handler 2 Ober Netze 5 (z.B. dem 
Internet) bidirektional durch geschlossene Datenverbin- 
dungen [6a. 6b, 6c] verbunden. Weiterhin besteht eine 
Datenverbindung 7 zwischen dem Finanzdienstleister 3 
und dem spezifischen Zahlungssystem 4 sowie inner- 
halb derer Strukturen (bsw. zu den zugeordneten Kon- 
ten). Der Finanzdienstleister 3 ist mit dem Kunden 1, 
abhangig vom spezifischen Zahlungssystem 4, uber tie 
Datenverbindungen 6a sicher verbunden, ebenso der 
Rnanzdienstleister 3 mit dem Handler 2 und dieser mit 
dem Kunden 1 uber die Datenverbindung 6b und 6a. 
Dies kann Hardware basierend Oder Software basie- 
rend durch geeignete Obertragungssysteme (bsw. uber 
VerschlOsselung mit einem 128brt SSL) erfolgen. Der 
Zahlungsvorgang zwischen dem Kunden 1 und dem 
Handler 2 erfolgt vollstandig innerhalb des spezifischen 
Zahlungssystems 4. Die Uberwachung und Steuerung 
des Zahlungsvorgangs uber spezifische Zahlungssy- 
steme 4 erfolgt uber das Vertragsmodul 8, welcher uber 
die RnanzdienstJeister-EDV 9 auf das Kbrrto des Hand- 
lers 2 zugreifen kann. Dazu stent der Vertragsmodul 8 
des Rnanzdienstleisters 3 des Handlers 2 uber je einen 
Zahlungssystemadapter 10 mit den jeweiligen spezifi- 
schen Vertragsmodul-Zahlungsmodulen 1 1 des zuge- 
hOrigen Zahlungssystems 4 im Datenaustausch. 
Innerhalb des Zahlungssystems 4 besteht intern ein 
Datenaustausch zwischen dem Kunden 1 und dem 
Finanzdienstleister 3 des Handlers 2 uber ein Kunden- 
Zahlungsmodul 12 und dem Vertragsmodul-Zahlungs- 
modul 11. AuBerhalb des Zahlungssystems 4 besteht 
ein Datenaustausch zwischen dem Vertragsmodul 8 
Ober ein Handler-Modul 13 und ein Auswahl-Modul 14 
mit dem Kunden 1 . Die einzeinen Funktionen zum Ver- 
fahren der Zahlungsabwicklung werden vorteilhaft uber 
ein separates ProzeBverwaJtungsmodul 15, ein Risiko- 
managementmodul 16 und ein Handlerverwaftungsmo- 
dul 1 7 innerhalb des Vertragsmoduls 8 ausgefuhrt Die 
Anpassung der einzeinen Protokolle zum Datenaus- 
tausch der Rnanzdienstleister-EDV 9 mit den en ande- 
rer erfolgt vorteilhaft uber einen optionaJen 
Protokollwandlermodul 18. Dieses Verfahren der Zah- 
lungsabwicklung unterstutzt bei dem Handler 2 im Ver- 
tragsprotokoll vorteilhaft ein neutrales Hander- 
Vertragsprotokoll 19 und bei dem Kunden 1 zur Zah- 
lungsabwicklung eine dem spezifischen Zahlungssy- 
stem 4 spezifische Zahfungsanweisung (20). Innerhalb 



des spezifischen Zahlungssystems 4 wird die Zahlungs- 
abwicklung uber eine spezifische Zahlungssystem-EDV 
21 (bsw. mft einem Zwischenkonto, welches als Sam- 
melkonto dient) vorgenommen. Die spezifische Zah- 
5 lungssystem-EDV 21 nimmt die ZahJungsanweisung 
des Kunden 1 bezGglich des Handlers 2 entsprechend 
den spezifischen Bedingungen im spezifischen Zah- 
lungssystem 4 vor. 

Die Zahlungsabwicklung erfolgt in nachfolgenden 
w Schritten: 

1. Schritt: 

[001 6] Durch Auswahl in einem Shoppingsystem des 
15 Handlers 2 erfolgt zuerst das Fullen eines Warenkorbes 
durch Kunden 1. Nach der Produktauswahl gibt der 
Kunde 1 dem Handler 2 an, mit welchem Zahlungssy- 
stem 4 er zahlen kann Oder mOchte. Er macht eine 
Preisanfrage bezOglich der verfOgbaren ZaMungssy- 
20 steme 4. Danach erfolgt durch den Handler 2 die Kun- 
deninitiaJisierung des Kunden 1, falls dieser noch nicht 
initiaiisiert ist Es ist vorstellbar, das dies dadurch 
geschieht indem der Kunde 1 das Auswahl-Modul 14 
als Plug-In oder Applet auf seinen PC Iddt und anschlie- 
25 Bend die Zahlungssysteme 4 konfiguriert die er unter- 
stutzen. Dabei gibt er diese vielleicht schon auf dem PC 
vorhandenen spezifischen Kunden-Zahlungsmodule 12 
an 

30 2. Schritt: 

[0017] Der Handler 2 tfitigt eine Bewertungsanfrage 
fOr tie Zahlungssysteme 4, indem er uber die Datenver- 
bindung 6b zu einem Vertragsmodul 8 bei einem 

35 Rnanzdienstleister 3 die Kondrtionen for die gewunsch- 
ten Zahlungssysteme 4 abfragt und dieses sie ihm 
sicher ubermrtteft Dabei arbertetder Handler 2 stets mit 
demselben neutralen Handler-Vertragsprotokoll 19. Die 
sichere Verbindung wird zwischen dem Vertragsmodul 

40 8 und dem Handler-Modul 13 aufgebaut Das Vertrags- 
modul 8 uberpruft die Produkt- und Zahlungsanforde- 
rungsinformationen auf ihfe Richtigkeit (und optional 
der Valtditat des Handlers 2). 

45 3. Schritt: 

[0018] Der Handler 2 ubermittelt uber die Datenver- 
bindung 6c dem Kunden 1 sicher ein Auswahl-Modul 
14, welches, jeweiis einzeln fur die gewunschten und 
so verfOgbaren Zahlungssysteme 4, das konkrete Angebot 
des Handlers 2 (Kaufabsichts- und Zahlungsartein- 
schrankungen) an den Kunden 1 beinhaltet. 

4. Schritt: 

55 

[0019] Der Kunde 1 wahtt ein einzelnes konkretes 
Angebot des Handlers 2 im Auswahl-Modul 14 aus (der 
Kunde 1 bestfitigt den Kauf und das Zahlungssystem 4) 



4 



7 



EP 0 907 134 A1 



8 



und gehl damh eine beidseitige Verpfiichtung ein, deren 
Inhatt das Auswahl-Modul 14 sicher Qber die Datenver- 
bindung 6c dem Handler 2 und sicher Qber die Daten- 
verbindung 6b dem Vertragsmodul 8 Obermittelt 
welches sie (die Produkt- und Zahlungsanforderungsin- 5 
formationen) auf ihre Richtigkeit (und optional der Vali- 
drtat des Handlers 2) uberpruft und bis zur Bestatigung 
der Zahlung unter der eindeutigen ProzeBnummer spei- 
chert AnschiieBend werden die Zahlungs- ProzeB- und 
Produktinformationen an das Clearingsystem des w 
Finanzdienstleisters 3 ubertragen. Es ist vorstellbar, 
daB ebenfalls eine Obertragung der Produktliste mrt 
entsprechenden ProzeBinformationen an den Kunden 1 
erfolgl 

15 

5. Schritt: 

[0020] Es erfolgt die standardisierte Zahlungsabwick- 
lung durch den Kunden 1 . Er aktiviert Qber das Aus- 
wahl-Modul 14 die (Or das ausgewahlte spezrfische 20 
Zahlungssystem 4 verfGgbare (ein spezifisches Kun- 
den-ZahlungsmoduJ 12 des Finanzdienstleisters 3 Oder 
das eines drrtten Zahlungssystembetreibers) sichere 
Datenverbindung 6a zwischen einem Kunden-Zah- 
lungsmodul 12 und dem zugeordneten spezifischen 25 
Vertragsmodul-Zahlungsmodul 11 und Obergibt den 
Inhatt der beidsertigen Verpfiichtung dem spezifischen 
Zahlungssystem 4. Optional erfolgt eine Vorinrtialisie- 
rung des Kunden-Zahlungsmodul 12 mit Betrag, Wah- 
rung und weiteren Oaten Es ist vorstellbar, daB das 30 
Kunden- Zahlungsmodul 12 des Finanzdienstleisters 3 
selbst stets verfOgbar ist indem es als Plug-In Oder 
Applet auf den PC des Kunden 1 ubertragen wird. 

6. Schritt: 35 

[0021] Der Kunde 1 nimmt die notwendigen Ergan- 
zungen in dem spezifischen Zahlungssystem 4 vor und 
weist die Zahlungsabwicktung mit dem Handler 2 Qber 
das spezrfische Kunden-Zahlungsmodul 12, die Daten- 40 
verbindung 6a und das spezrfische Vertragsmodul-Zah- 
lungsmodul 11 sicher an. Dabei arbertet der Kunde 1 
mit den gewohnten spezifischen Zahiungsanweisungen 
20 seines gewahtten Zahlungssystemanbieters. Es ist 
vorstellbar, daB der Finanzdienstleister 3 fur den Kun- 4$ 
den 1 uberhaupt nicht erkenrtbar in Erscheinung trrtt 

7. Schritt: 

[0022] Das spezrfische Vertragsmodul-Zahlungsmo- so 
dul 1 1 tatigt die angewiesene Zahlungsabwicklung uber 
die spezrfische Zahlungssystem- EDV 21 an ein Zwi- 
schenkonto des spezifischen Zahlungssystembetret- 
bers. Die Zahlungsantwort des spezifischen 
Zahlungssystems 4 wird vom Vertragsmodul 8 regi- 55 
strierl Bei erfblgrachem Zahlungseingang wird der 
Betrag spater dem (Clearing) Sammelkorrto des 
Finanzdienstleisters 3 gutgeschrieben und in das Kon- 



ten- oder Verwaltungssystem eingetragen. 

8. Schritt: 

[0023] Das Vertragsmodul 8 liest uber die spezifische 
Zahlungssystem-EDV 21 das Zwischenkonto des spezi- 
fischen Zahlungssystembetreibers, vergleicht dessen 
Eintrage mit dem gespeicherten Inhart der beidseitigen 
Verpfiichtung und informiert sicher Qber die Datenver- 
bindung 6b den Handler 2 uber den Status der Zah- 
lungsabwicklung (Zahlungsbestatigung). Dadurch hat 
das Vertragsmodul 8 die Erfullung der sich aus dem 
betdseitig verpflichtenden Vertag ergebende Zahlungs- 
verpfiichtung uberwacht, wobei die Zahlungsabwick- 
lung direkt uber spezrfische Zartlungssysteme 4 
erfolgte. Der Handler 2 hat die Gewahr (fur deren Erful- 
lung der Finanzdienstleister 3 burgen kann), daB die 
Zahlungsverpflichtung des Kunden 1 erfullt wurde und 
kann seinerserts die Ware an den Kunden 1 ubereig- 
nen. 

9. Schritt: 

[0024] Die Clberweisung vom Zwischenkonto auf das 
Konto des Handlers 2 erfolgt Es ist vorstellbar, daB in 
vereinbarten zertiichen Abstanden eine Abarbeitung der 
getatigten Transaktionen erfolgt, bsw. ein Abgleich der 
Eingange auf das Sammelkorrto mit deren Abbuchun- 
gen, eine Fehler- und Sondertallbehandlung bei ProUe- 
men, eine Provisionsabrechnung fur den Handler 2, ein 
monarches Versenden der Abrechnung (auch elektro- 
nisch oder auf Papier in unterschiedlichen Detailie- 
rungsgraden mdglich) usw. 

Vorteilhaft ist im 10. Schritt: 

[0025] Der Handler 2 erstattet dem Finanzdienstlei- 
ster 3 eine Gebuhr entsprechend eines Vertrages zwi- 
schen dem Handler 2 und dem Finanzdienstleister 3. 
So ist es denkbar, daB bei der Clberweisung der Betrage 
an den Handler 2 eine Provision des Finanzdienstlei- 
sters 3 einbehatten wird, bsw. indem Qber das Protokoll- 
wandlermodul 1 8 die Uberweisungen vom 
Sammelkorrto an die Handlerkonten (bsw. Girokonto), 
abzQglich der Margen des Clearingbetrebers, initiiert 
werden. So ist es vorteilhaft vorstellbar, daB die einzel- 
nen Kunden 1 abhangig von Zahlungssystem 4 und 
Risikogruppe mit den realen Kosten der Geldbeschaf- 
fung bewertet werden (incl. Rabat durch Volumen und 
Margen). Diese kflnnen in Sammelkonten zusammen- 
gefaBt mft den Systembetreiberkosten (ca. 0,1%) 
beaufschlagt sowie mrt weiterberechneten Kosten und 
auf die etnzelnen Handlerkonten aufgeteift werden. 
[0026] BezQglich der Gewahrieistung etner sicheren 
Datenverbindung 6a, 6b, 6c ist es vorstellbar, daB vor- 
bekannte kryptographische Systeme in der nachfolgen- 
den Art verwendet werden: 

Der Handler 2 sendet ein teilweise verschlussertes 
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Datenpaket (bsw. bestehend aus: verschlOssette Ware, 
unverschlusselte Ware, Zahlungstyp, eindeutige Pro- 
zeBnummer, Hashwert der verschlQssetten Ware, Regi- 
sternummer des Handlers 2 und dessen Signatur, 
Public Key des Handlers 2) an den Kunden 1 (ohne 5 
Kundendaten und Warendaten). AnschlieBend pruft der 
Kunde 1 die Transaktionsdaten auf ldentitat (bsw. pruf- 
bar mit einem zertifizierten Public Key) und fuhrt eine 
Uberprufung des verschlDsselten Wareninhatts (bsw. 
durch Hash-Erzeugung uber dem lesbaren Wareninhaft w 
und Vergleich mit dem mitgelieferten Hash des ver- 
schlussetten Wareninhatts). AnschlieBend sendet der 
Kunde 1 das Datenpaket an das ProzeBverwattungsmo- 
dul 15 des Finanzdienstleisters 3 (gegebenenfalls mit 
Angaben zum Zahlungstyp erganzt). Der Rnanzdienst- 15 
leister 3 selbst erhait nur eine ProzeBnummer. Die 
Transaktion wird vom Vertragsmodul 8 angenommen 
und das eigentliche spezifische Vertragsmodul-Zah- 
lungsmodul 11 aufgerufea wobei die ProzeBnummer 
wertergelertet wird. Das spezifische Vertragsmodul- 20 
Zahlungsmodul 1 1 baut spezrf isch eine sichere Verbin- 
dung 6a zum spezrf ischen Kunden-Zahlungsmodul 12 
auf. AnschlieBend erfblgt die AbwicWung der Zahlung 
(zwischen dem spezrf ischen Zahlungssystembetreiber 
3 und dem Kunden 1). 25 
Das ProzeBverwattungsmodul 15 erhatt aJs Ergebnis 
nur, daB die Zahlung mit der entsprechenden ProzeB- 
nummer abgewickeft wurde Oder nicht im letzen Fall 
erfotgt eine errtsprechende Fehlermetdung. Die Eigen- 
schaften des entsprechenden Zahlungsmittels des spe- 30 
zrf ischen Zahlungssystems 4 (z.B. Anonym itat) bleiben 
uneingeschrankt ematten. Nach erfolgter Zahlung sen- 
det das ProzeBverwattungsmodul 15 die ProzeBnum- 
mer und die Bestatigung der eingegangenen Zahlung 
an den Handler 2. 35 

Verwendete Bezugszeichen 
[0027] 

40 

1 Kunde 

2 Handler 

3 Finanzdienstfeister 

4 Zahlungssystem 

5 Netz 45 

6 [a. b, c] geschlossene Datenverbindung 

7 Datenverbindung 

8 Vertragsmodul 

9 Ftnanzdienstleister-DVA 

1 0 Zahlungssystemadapter so 

1 1 speziftsches Verlragsmodul-ZahtungsmoduJ 

12 speziftsches Kunden-Zahlungsmodul 

13 Handler-Modul 

14 Auswahl-Modul 

15 ProzeBverwattungsmodul ss 

16 Risikomanagementmodul 

1 7 Handlerverwattungsmodul 

1 8 Protokolrwandlermodul 
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1 9 Handler-VertragsprotokDll 

20 spezifische Zahlungsanweisung 

21 spezifische Zahlungssystem-OVA 

Paterrtanspruche 

1. Veriahren zur rechnergestutzten Zahlungsabwick- 
lung uber Zahlungssysteme, bei welchem ein 
Kunde (1) uber eine Datenverbindung (6c) die Wer- 
bung eines Handlers (2) pruft eine beidsertige Ver- 
pflichtung einzugehen beabsichtigt und die ihn 
irrteressierenden gewunschten Waren und Zah- 
lungssysteme (4) auswahtt, dadurch gekenn- 
zeichnet, daB 
in einem 1 . Schrrtt 

der Kunde (1) seine gewunschten Waren und Zah- 
lungssysteme (4) dem Handler (2) uber die Daten- 
verbindung (6c) mitteitt und danach durch den 
Handler (2) die KundeninrtiaJisierung des Kunden 
(1) erfolgt, 
in einen 2. Schritt 

der Handler (2) uber eine Datenverbindung (6b) zu 
einem Vertragsmodul (8) bei einem Rnanzdienst- 
leister (3) die Kondrtionen fur die gewunschten Zah- 
lungssysteme (4) abfragt und dieses sie ihm sicher 
ubermittert, 
in einem 3. Schritt 

der Handler (2) uber die Datenverbindung (6c) dem 
Kunden (1) sicher ein Auswahl-Modul (14) ubermit- 
tert, welches, jeweiis einzeln fur die gewunschten 
und verfOgbaren Zahlungssysteme 4, das konkrete 
Angebot des Handlers (2) an den Kunden (1) 
beinhattet, 
in einem 4. Schritt 

der Kunde (1) ein einzelnes konkretes Angebot des 
Handlers (2) im Auswahl-Modul (14) auswahtt und 
damit eine beidsertige Verpflichtung eingeht, deren 
Inhatt das Auswahl-Modul (14) sicher uber die 
Datenverbindung (6c) dem Handler (2) und sicher 
uber die Datenverbindung (6b) dem Vertragsmodul 
(8) ubermrttelt welches sie auf ihre Richtigkert 
uberpruft und urrter der eindeutigen ProzeBnum- 
mer speichert 
in einem 5. Schritt 

das Auswahl-Modul (14) die fur das ausgewahtte 
spezifische Zahlungssystem (4) verfOgbare sichere 
Datenverbindung (6a) zwischen einem spezrfi- 
schen Kunden-Zahlungsmodul (12) und dem zuge- 
ordneten spezrf ischen Vertragsmodul - 
Zahlungsmodul (11) aktiviert und den Inhatt der 
beidsertigen Verpflichtung dem spezrf ischen Zah- 
lungssystem (4) ubergibt 
in einem 6. Schritt 

der Kunde (1) die notwendtgen Erganzungen in 
dem spezrf isch en Zahlungssystem (4) vomimmt 
und tie ZahlungsabwicWung mit dem Handler (2) 
uber das spezifische Kunden-Zahtungsmodul (12), 
ole Datenverbindung (6a) und das spezifische Ver- 
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tragsmodul-Zahlungsrnodul (11) sicher anweist, 
in einem 7. Schritt 

das spezifische Vertragsrnodul-Zahlungsmodul 
(11) die angewiesene Zahlungsabwicktung an eine 
spezifische Zahlungssystem-DVA (21) des spezrfi- 5 
schen Zahlungssystembetreibers tatigt 
in einem 8. Schritt 

das Vertragsmodul (8) die spezifische Zahlungssy- 
stem-DVA (21) des spezifischen Zahlungssystem- 
betreibers liest dessen Eintrage mit dem w 
gespeicherten Inhatt der beidsertigen Verpf lichtung 
vergleicht und Qber die Datenverbindung (6b) den 
Handler (2) sicher Qber den Status der Zahlungsab- 
wicWung informiert 

in einem 9. Schritt 15 
die Uberweisung von der spezifischen Zahlungssy- 
stem-DVA (21) auf das Konto des Handlers (2) 
erfolgt 

2. Verfahren zur rechnergestotzten Zahlungsabwick- 20 
lung Qber Zahlungssysteme nach Anspruch 1, 
dadurch gekennzeichnet 

daB der Handler (2) dem Finanzdienstieister (3) 
eine GebQhr errtsprechend eines Vertrages zwi- 
schen dem Handler (2) und dem Finanzdienstlei- 2s 
ster (3) erstattet 

3. Verfahren zur rechnergestotzten Zahlungsabwick- 
tung Qber Zahlungssysteme nach einem der 
Anspruche 1 Oder 2, dadurch gekennzeichnet, 30 
da 3 zur Gewahrletstung einer sicheren Datenver- 
bindung (6a). (6b), (6c) kryptographische Systeme 
verwendet werden, indem 

im (3) Schritt 

der Handler (2) ein teilweise verschlussertes Daten- 35 
paket an den Kunden (1) sendet, 
im (4) Schritt 

der Kunde (1) die Transaktionsdaten auf Identitat 
pruft und eine UberprOfung des verschlOsseften 
Wareninhalts durchfOhrt. nach dem Eingehen der 40 
beidsertigen Verpf Bchtung der Kunde (1) das 
Datenpaket Qber den Handler (2) an das ProzeB- 
verwattungsmodul (15) des Rnanzdienstleisters (3) 
sendet, der Rnanzdenstleister (3) sefbst nur eine 
ProzeBnummer erhdlt die Transaktion vom Ver- 45 
tragsmodul (8) angenommen und das eigenttiche 
spezifische Ven>agsmodul-Zahlungsmodul (11) 
aufgerufen wird, wobei die ProzeBnummer weiter- 
gelertet wird, 

im 6. Schritt 50 
die AbwicMung der Zahlung zwtschen der spezifi- 
schen Zahlungssystembetreiber und Kunden (1) 
errtsprechend der Datensicherhert des spezifischen 
Zahlungssystems (4) erfolgt das ProzeBverwal- 
tungsmodut (15) nur als Ergebnis erhaJt, daB die ss 
Zahlung mrt der errtsprechend en ProzeBnummer 
abgewtckelt wurde Oder nicht wobei im (etzen Fall 
eine entsprechenden Fehlermeldung erfolgt, nach 



erfolgter Zahlung das ProzeBverwaftungsmodul 
(15) die ProzeBnummer und die Bestatigung der 
eingegangenen Zahlung an den Handler (2) sen- 
det. 
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